Generally, when unauthorized users break into computer systems, they accomplish this either by attacking systems that have been incompletely set up or by maliciously exploiting weak points, called security holes. Intruders can also access systems by surreptitiously exercising access rights belonging to other persons, and can, by exploiting the opportunities such entries afford them, acquire network administrators privilege levels for use in future attacks.
A typical attack one called stack smashing. Such an attack can be especially damaging, since return addresses are stored in stacks, along with local variables and arguments, to maintain the execution status of sub-routines. A stack smashing attack involves the application of a procedure used to rewrite return addresses in a stack so that control of an operation can be shifted to a maleficent program.
A stack smashing attack will be specifically explained by employing a stack structure. FIG. 9 is a diagram showing a stack after a function is called in the C language. Referring to FIG. 9, a local variable (LV), a frame pointer for a preceding function (a Previous Frame Pointer: PFP), which is a calling source for the pertinent function, and a return address (RA) for returning to the calling source are stacked in order, reading from the stack top. The frame pointer (FP) is a base pointer for relatively referring to the local variable. During a stack smashing attack, a substitution into the local variable (especially, a data array) is performed, and when the boundary check is incomplete, the stack area above the local variable is destroyed. When the stack area is to be destroyed, a program is written into a memory, as is also a value indicating the program has been written in the return address areas. Thus, if a function return process is performed in this state the newly written program will be activated.
A stack smashing attack will be more specifically explained by using a program written in the C language. FIG. 10 is a diagram showing an example C language program that is the target of a stack smashing attack, and FIG. 11 is a diagram for explaining the configuration of a stack when the stack smashing attack is launched against the program. In FIG. 10, “foo” is a function used for copying the contents of an environment variable HOME to a local variable. Since the library function “strcpy” does not take into account the size of the local variable, when 128 or more characters are contained in the environment variable HOME, the contents (the shaded portions) above “buf” in FIG. 11 are destroyed by overwriting them and embedding a malign program in the stack. The head address of the embedded program is positioned in the return address area, so that control of the operation is effectively shifted to the embedded intruder.
As a result of a described stack smashing attack, an unauthorized user, who has gained access to a computer network managed by another party, could siphon off confidential information or could destroy the computer network system. Further, after embedding the program, the unauthorized user would be able to steal any number of IDs and passwords assigned to authorized users, and would then be able to use these authenticators to make further invasions while disguised, or could use them to support attempts to invade other computer systems.
Conventionally, this type of stack smashing attack has mainly been directed against UNIX servers. Recently, however, buffer overflows involving ActiveX (Acrobat Control for ActiveX; ActiveX is a trademark of Microsoft Corp.) have become problems, and units on which ActiveX is used have become the targets of stack smashing attacks. As a result, the general run of computers connected to networks, i.e., all server machines, client machines and PDAs, could be targeted for attack.
In general, the problem has been that bugs have not been removed until after buffer overflows have occurred. Thus, in order to prevent attacks during which the presence of bugs is exploited, it is generally accepted that specific countermeasures should be instituted to prevent such events. As a result, a variety of conventional means have been proposed for preventing computer system intrusions.
As an example of these conventional techniques, the program StackGuard is disclosed, for example, in the reference, “Automatic Detection And Prevention Of Buffer-Overflow Attacks,” Crispin Cowan, Calton Pu, David Majer, Heather Hinton, Peat Bakke, Steve Beattie, Aaron Grier, Perry Wagle, and Quan Zhang the 7th USENIX Security Symposium, San Antonio, Tex., January 1998. According to the employment of StackGuard, special value, a “guard_value,” for protection of return addresses is inserted between the return address area in the stack in FIG. 9 and the frame pointer area that constitutes the calling source. Then, during a function return process, the validity of the guard_value is examined to confirm the presence/absence of an attacking program.
In addition to this conventional technique, other methods have been proposed: a method for operating a virtual memory page, and for inhibiting the writing of data in the return address storage location in a stack; or a method for protecting a return address by separately preparing a dedicated stack for its storage, for copying the return address to the special stack at the time a function is executed, and for returning the return address from the dedicated stack during a function return process. Further, in order to prevent all attacks precipitated by buffer overflows, a method can be employed to check the boundaries for all array accesses.
However, the conventional techniques for preventing the computer system intrusions, as is described above, have the following shortcomings.
According to the StackGuard program described in the above mentioned reference, the guard_value is stored between an address to be used to return to a preceding function, which is the calling source for the function that is currently being executed, and the frame pointer (hereinafter referred to as a PFP) at the preceding function. Thus, while the return address is protected, the frame pointer that is used to describe the scope of the variable is not, and this constitutes a serious security hole.
In other words, since the frame pointer is not protected, intrusive control of the program counter is possible. An overview of the problem will now be explained.
In the function return processing, the following transactions take place.    FP→SP    PFP→FP    (SP)→PF; return operationHere, FP denotes a frame pointer, SP denotes a stack pointer and PC denotes a program counter; an arrow is used to indicate the substitution of a value; and the parentheses are used to identify a direct reference.
As is shown above, since the StackGuard program does not protect the PFP in a stack, the value of the PFP can be controlled by an external attack. And when the transmission of the value is examined and the above function return processing is referred to, only the PFP need be used to control the frame pointer at the first return and to control the program counter at the second return. While actually a test based on the guard_value must be passed in order to embed malicious code, a stack smashing attack can be delivered to the guard_value that is used as a default by the StackGuard. Furthermore, a method for attacking the other guard_value may also be found.
Therefore, the conventional method for which the StackGuard program is used can not completely prevent a stack smashing attack.
In addition, according to the StackGuard program, the validity of the guard_value must always be confirmed at the time of the second return in order to detect to what degree the frame pointer is affected that was damaged at the first return. Therefore, for all the functions the program is produced to confirm the validity of the guard_value. As a result, overhead is always incurred because of the process for confirming the validity of the guard_value.
Further, since according to the StackGuard program the guard_value is inserted between the return address area and the PFP area, the frame structure of the stack is changed, and therefore, debugging support can not be provided for a program for which the StackGuard is mounted.
According to the conventional technique for operating a virtual memory page and for inhibiting the writing of data in a return address storage location in a stack, although the return address is protected, the frame pointer is not. Therefore, a security hole is present other than the one for which StackGuard is deployed, and full protection can not be provided to prevent a stack smashing attack.
Further, since control is shifted to a supervisory mode when data is written in a stack, the overhead required for the execution is exceedingly large.
According to the conventional technique whereby a separate, dedicated stack is prepared for the storage of a return address, and whereby a return address is copied to the dedicated stack when a function is called and is returned to the original stack the dedicated stack when the execution process is returned to the calling function, a direct attack on the return address can be delivered. That is, since the return address is returned from the dedicated stack prepared in the global variable area to the original stack without the validity of its value being confirmed, an attack on an operation for returning the return address from the dedicated stack would constitute a direct attack on the return address. For this conventional technique, the required overhead for the management of the dedicated stack is also exceedingly large.
When, however, boundary checking is performed for all the array accesses, as is described above, all attacks due to buffer overflow can be prevented; but for the program, since it mainly involves the use of a pointer, once more the overhead is exceedingly large.
To resolve the above technical shortcomings, it is one object of the present invention to completely prevent a stack smashing attack that is caused by the overflow of a buffer in a stack.
It is another object of the present invention to reduce the execution overhead related to the employment of stack smashing attack prevention means.